Greetings. I’m sure some of you have wondered where Imagery had gone to - it has been almost two years since the last release. Alas, major work problems lead to almost no free time for me to work on Imagery. (This wouldn’t be that bad a thing if I could say I made a lot of money doing all that work - but I didn’t. Ah well.)
Anyway, Imagery should be back on track again and so without any further delay, here is Imagery 1.9.
New Features
Imagery now allows you to save a preferred conversion setup and allows you to convert batches automatically by drag-dropping files over the Imagery icon while holding down the Command key.
Preview icons can now be added automatically by selecting an option in the output format selection dialog (see documentation).
EPSF files can include a Macintosh compatible preview as well.
IMPORTANT NOTE!
Imagery 1.9 requires System 7.0 or later and Quicktime 1.6.1 or later.
This version of Imagery requires Quicktime 1.6.1 or later for some of its features, and relies heavily on the offscreen bitmap features found in System 7.0 or later. Originally, my goal was to make sure that everyone, including users of System 6 and owners of 68000 based Mac, could convert graphics files on their choice of systems and machines. Alas, the sheer overpowering weight of new features and programmer support in System 7.0 and even more so in 7.1, and in Quicktime, which only works on 68020 and higher Macs compels me to move on.
The fact is that a new colour capable Macintosh is cheaper than your original MacPlus or SE and will give you many great new features. Similarly, System 7 is just too good an improvement over System 6 to put off using any longer. I know that System 7 eats up a lot more memory - try 7.5 with Quckdraw GX if you really want to see your memory vanish - but the truth is that you get a lot for that memory.
For owners of older Macs who cannot afford to upgrade - hey, I hear you and I know what you’re going through. For what it’s worth, this was not an easy decision for me to make. However, I want to get on with using the new features of System 7 and I don’t want to have to write a whole version of MacOS to simulate the features I want to use in System 6.
The next version of Imagery will be even more tightly coupled to System 7, probably requiring features only found in System 7.1 or later, so be warned.
New Formats
Sounds and Movies. Imagery now supports converting several sound formats from various machines.Technically, this is outside the scope of Imagery which is supposed to be a graphics converter, but I got tired of all the strange sound converters which wouldn’t just simply convert my file, but insisted on bringing up all sorts of issues. So, Imagery now simply converts sound files.
The sound file formats currently supported on input are:
Extension† System Format Status Description
.SND IBM PC Sound Tested SND Sound File.
.SOU IBM PC Sound Tested SOU Sound File.
.VOC IBM PC Sound Tested Creative Systems VOC Sound File.
‘FSSD’ Macintosh Sound Tested SoundWave Sound File
‘jB1 ‘ Macintosh Sound Tested SoundEdit Sound File
‘Sd2f’ Macintosh Sound Tested Sound Designer II Sound File
.AU Unix Sound Tested Sun/NeXT Sound File
.WAV Windows Sound Tested Windows WAV Sound File
.
The sound file formats currently supported on output are:
Extension† System Format Status Description
‘snd ‘ Macintosh Sound Tested System 7 Sound File
‘AIFF’ Multisys Sound Tested Apple AIFF File
‘jB1 ‘ Macintosh Sound Tested SoundEdit Sound File
.WAV Windows Sound Tested Windows WAV Sound File
Note that Extension refers to the file name extension or to the Macintosh file signature (type) code. Since Imagery automatically detects the format of Macintosh files, you shouldn’t have to worry about this for Mac files, but for PC files, the filename is usually one to eight characters followed by a period and upto three more characters. The “period and upto three characters” are the extension for the file. On PCs, this is used to identify what kind of file the file is and Imagery also uses this as in many cases, it is the only way to tell what kind of file a file is.
More Bitmap Output Formats
Imagery now generates more bitmap output formats:
Extension† System Format Status Description
‘EPSF‘ Macintosh Bitmap Tested Photoshop 2.5 compliant EPSF file with preview
‘PICT’ Macintosh Bitmap Tested Standard Macintosh PICT2 file
.PCX IBM-PC Bitmap Tested ZSoft PCX file
.TGA IBM-PC Bitmap Tested Targa file
.JPG Multisys Bitmap Tested JFIF standard JPEG compressed file
.GIF Multisys Bitmap Tested Compuserve GIF file
JPEG Support Integrated
Imagery now supports JPEG/JFIF file input and output directly within Imagery. No new versions of Imagery-JPEG will be released. Note, this requires Quicktime and a Color Quickdraw capable Macintosh.
Quicktime 1.6.1 requires a mere 20K of system heap when not in use and I argue that this is such a small overhead for so many features that everyone who can run it should have Quicktime 1.6.1 or later on their system.
Applications Files
If an application is dropped onto Imgery, it will find all ‘ICON’ and ‘PICT’ resources and convert them into the selected output format. This was added as a quick way to generate PC compatible files for porting Mac applications to Windows or to aid programmers in creating documentation for Mac applications.
Animation Files
These formats are supported differently. The Atari formats are treated as a sequence of bitmap images while the FLI/FLC files are actually treated as animation files and are converted to Quicktime. The Atari formats as well as Amiga ANIM and ANM files will be added to full Quicktime support in the next release.
Extension† System Format Description
.ANI Atari ST Animation Neochrome Animation File
.FLM Atari ST Animation Animatic Film
.IC1 Atari ST Animation Imagic Film/Picture File (16 clr)
.IC2 Atari ST Animation Imagic Film/Picture File (4 clr)
.IC3 Atari ST Animation Imagic Film/Picture File (mono)
.FLC IBM PC Animation FLI Autodesk Animation File.
.FLI IBM PC Animation FLI Autodesk Animation File.
Bug Fixes
A bug which caused some GIF files to crash has been fixed.
A bug which caused the TIFF writer to create files which were incompatible with many TIFF readers seems to have been fixed.
More protection for memory overwrites and running out of memory has been added. A simple disk caching system has been added (this will be improved in the next release).
Problems with palettes in various modes have been fixed.
What's New in Version 1.8.5
New formats
Macintosh(tested)
Generic PICT/PICT2
All formats, restricted to current screen resolution.
Generic(tested)
TIFF 4/5 - all formats PC or Mac
All compression modes defined in the 8/8/88 version of the TIFF 5 manual are supported.
Fixes and improvements
Colour map errors for several modes should be fixed now.
Apologies
First to Phillip Wing for listing him as Paul Wing, and Jay van Vark for listing him as Jay van Ark in previous versions of the manual.
What's New in Version 1.8
New formats
Macintosh(tested)
Photoshop (8BIM)
Grey, RGB and CMY/CMYK only. HSL, HSV and multichannel not supported.
Thunderscan (SCAN)
1, 4 and 5 bit files.
Imagestudio RIFF (Raster Image File Format)
Grey, RGB and CMY/CMYK only. HSL, HSV not supported.
"TPIC" Targa Files
Now map to ".TGA" files (see below).
IBM-PC(tested)
Targa (TGA)
Uncompressed modes have been tested. RLE not tested, Complex not supported.
Lotus PIC files
(Note, the handling of text in this mode is not the best... Thanks to Lotus for docs)
The type of ".PIC" is automatically detected.
Apple IIgs(tested)
Super-HiRes (.SHR) files.
Apple IIgs(partially tested)
Apple Preferred (.PNT) files. (Thanks to C. K. Haun)
Generic (tested)
"RAW" file import. See section on this mode as it is fairly complex.
Fixes and improvements
New file icons for generated files which more clearly identify the type of image saved.
Imagery now has a rather simple image viewing feature. If you select "Display" as an output format, the file will be converted then displayed. Please note, this feature works best under System 7 and may not work for 24bit files under System 6. Please note, this was thrown in more as a thought exercise and it's pretty lame... next version should be better and offer more features.
IBM-PC PCX mode has been completely rewritten. Should work with just about everything.
IBM-PC BMP now handles more variants (Thanks to Jay Van Vark for these)
XWindows XWD pixel/byte order bug fixed. Should handle more images.
(Thanks to Jim McGowan for his samples)
Future enhancements
The next version will include Targa "TGA" and ZSoft "PCX" output. I have been told that a lot of "high-end" drawing programs for the PC can only support TGA files and that many other lower-end drawing programs can only support PCX. For example, Windows' Paint program only supports BMP and PCX (which is all the stranger when you consider that Microsoft was one of the two original designers of TIFF...). I may also add an "IFF" output mode for Amiga users.
What's New in Version 1.7
Fixes and improvements
IBM PIC, GL and PCX format support improved. Fewer crashes.
(Thanks to Phillip Wing and Paul Jacoby for pointing out the problem)
Complete overhaul of memory checking done. Fewer crashes on unusual files. FIxes peculiar hehaviour on mac IIsi and IIcis.
(Thanks to Candi on AOL and Wally for their help.)
Amiga IFF-HAM colour translation now correct and ".HAM" or ".LBM" extensions are recognised.
(Thanks to Mike Monaco for his help)
New Features
PICT2 24bit files are now possible. Those formats which required that format, such as Amiga HAM files, now work. Also, all PICT2 files now use the "dither" copy mode which will let them translate better on monochrome and non-colour Quickdraw Macs. Note, you require System 7 to see 24-bit direct colour images.
Known Problems
GIFLite
It seems that there is some sort of GIF "supercompressor" called GIFLite which is only available for the PC. It seems to compress GIF files upto an additional 25% and claims to keep the files compatible with standard GIF. According to Paul Wing, some will work with Imagery but others crash seriously. I'm afraid that at this time, I have no intention to support this variant of GIF. If you do have problems with GIFLite files, try GIFConverter.
Lotus PIC Files
As I mention later in this document, MS-DOS tends to rely on a simple three letter extension to identify what the contents of a file are. Not surprisingly, some three combinations, such as "DOC", "TXT" and "PIC" get used a lot. Lotus and Pictor both use the "PIC" extension, but the files are very different inside. Imagery cannot read Lotus PIC files at this time, although I am attempting to locate documentation on this file format.
General Thanks
Thanks to Stu Gove for giving the Sun Raster section a good testing, to Gary Kessler for his excellent suggestions and of course, Paul Jacoby for poking where necessary when necessary.
What's New in Version 1.6
New formats
Unix (tested)
Sun Raster Files (.RAS)
Fixes and improvements
Critical failure in Atari ST PC1, PC2 and PC3 format conversion fixed.
(Thanks to Ewen Wannop for pointing out the problem)
Some GRASP GL files would cause lockup and bizarre offsets - fixed.
(Thanks to Paul Jacoby and Harry@UMSLVMA.UMSL.EDU for their help)
What's New in Version 1.5
New formats
IBM-PC (untested)
QRT Raytrace (.QRT) files
MTV Raytrace (.MTV) files
IBM-PC (tested)
.IMG DRI GEM Image files (mono & colour)
Unix (tested)
XWindows Window Dump Files
(.XWD - Thanks to Michael Garnett for the sample file)
XWindows XBitmap Files (.XBM - Thanks to Mike at NCSU for the generator program)
Portable Bitmap (.PBM .PGM .PPM) files
Unix (untested)
Sun Raster (.RAS) files
CMU Window Manager Dump Files (.CMU)
MGR Window Manager Dump Files (.MGR)
FITS Files (.FIT)
HIPS Files (.HIP)
Usenet FaceSaver Files (.FSV)
Xerox Doodle Brush File (.XDO)
Additions to existing formats
Amiga IFF Extra-halfbright mode is now supported. (Untested)
Fixes and improvements
PIC decoder could hang on improperly created files and colours were sometimes incorrectly translated. These problems have been fixed.
Previous versions of Imagery would allow you to select an output format which has fewer bits per pixel then the current image. In fact, Imagery doesn’t support this yet with the result that the output file contains gibberish. For example: if the original file was a four bit palette image and the output was TIFF B/G, the output file would be a four bit grey image, but no mapping for the colours would take place - the image would look strange. Similarly, a 24 bit RGB image would generate total garbage if TIFF P or TIFF B/G were selected. However, most of the 24 bit RGB modes override the user selection, so this has not been seen too often.
This version of Imagery is smarter about such things and will not let you select an inappropriate mode, forcing the selection to the lowest valid one. There is no way to generate a TIFF-B monochrome bitmap from a grey or colour image in this version. That feature will be available in v2.0 which is slated for release at the end of March or April 1992.
New features
In answer the the many requests for PICT2 and GIF output, Imagery now offers these output formats. PICT1 (old pict) is not supported, but since System 6.0.5, all Macs including those without colour quickdraw have been able to decode colour PICT2 files. GIF files are always interlaced - since the primary use for GIF is to upload images, they should be interlaced as this lets a downloader preview the image in less than 1/8th the file's full download time. Imagery does not support GIF files of more than eight bit (256 colour) depth nor PICT2 files for 24 or 32 bit colour (yet).
What's New in Version 1.2
New formats
IBM-PC EGAPaint/ColoRIX RIX files (untested)
Additions to existing formats
Atari ST DR Doodle (DOO) and STad PAC format's now tested
(Thanks to Wolfgang Lang for the sample files)
Fixes and improvements
Better on-line file support documentation
Monochome TIFF-P palette now automatically generated
What's New in Version 1.1
New formats
Compuserve's GIF
Compuserve RLE and C-RLE
IBM Targa files (modes 0, 1, 2, 3, 9, 10 and 11) (untested)
Atari FCP (Flash Colour Picture) version of RLE
Atari IMG files (IBM IMG files not supported yet)
- old format, STTT and XIMG formats supported
Additions to existing formats
Window's BMP compressed files (BMP4 and BMP8)
Amiga IFF RGBN and RGB8 files
Fixes and improvements
IBM GRASP control file now written as TEXT file
IBM GRASP image files are now automatically converted to TIFF
User can now select destination directory
Abstract
Imagery is a simple utility which converts a range of graphics files from the IBM PC, Macintosh, Apple IIgs, Atari ST, Unix and Amiga computers. The program generates standard TIFF files in TIFF 4.0/5.0 format compatible with Freehand, Digital Darkroom, Superpaint and many other drawing and editing programs.
Introduction
Like many people who wanted a Macintosh but couldn’t afford one, in 1985 I bought an Atari ST - one of the first in Canada and the very first one in Alberta. Within a year, Dave Small created a gimmick called “MagicSac” which allowed an ST to work like an old 64K ROM version Mac.
I managed to get a lot done on a single 400K drive system with about 400K free memory. Later I added a second 800K drive. However, when Small left his company to form a new company which created a 128K ROM version of MagicSac called Spectre 128 (later Spectre GCR), I found myself with an interesting problem.
To upgrade my ST to the point where it could be seriously useful with Spectre, not to mention buying the Spectre and obtaining a legal set of Mac 128K ROMs - which was becoming increasingly difficult, I would end up spending almost as much as buying a brand new Macintosh SE.
Also, Atari had a bad upgrade record with me. My original machine did not have ROMs, although the advertising guarenteed them. Same for an internal RF modulator. Atari never offered the RF modulator as an upgrade and only offered the ROMs as a $30 upgrade. Not much, I appreciate, but I had already more than paid for them. Well, when I asked Atari how I could upgrade my Atari ST to STm level (let alone STe), I was told “You’ll have to buy a new machine” - so I did... a Macintosh.
However, I was stuck with a lot of Atari image files in five or six formats (Degas, Degas Compressed, Neochrome, NVision and a handful of random singles) none of which were compatible with each other, let alone with anything on the Mac.
So, I wrote a program then called “TIFF-ST” which converted all of these various formats into TIFF files. I chose TIFF for a couple of reasons. First, it is a standard and an easily implimented one. It’s not proprietory. There is no special complex compression system unless you choose to use it and virtually all Mac graphics programs can use a version of TIFF.
Later, I found I was getting Amiga IFF files as well as a variety of IBM PC graphics files such as GRASP and PCX. With Windows, BMP was added to the list. I added these to the original TIFF-ST program and changed its name to Imagery.
Since then, I have spent a quite a bit of time and effort gathering nearly 4.3MB of information on every file format I can find. I am compiling these files into a single document which I hope to post or publish sometime early next year. Many of these graphics formats have been added to Imagery and I am still adding more with the addition of PICT based images to handle a
collection of vector based image formats such as DXF, IGES and CGM to occur in version 2.0.
Usage
Imagery is very simple to use and under System 7 can be used in two different ways.
The simplest way is to launch the program by double clicking the Imagery icon or by selecting the Imagery icon then selecting Open... from the File menu. The first dialog box is a copyright notice which can be dismissed by hitting Enter or Return or by clicking on "Ok".
The biggest new feature here is the replacement of the multiple system specific panels in previous version which listed supported formats and their status, with a single scrolling list box and a notice indicating the number of formats and variants supported in this version of Imagery. A variation of a format typically is a format which has more than one extension - the worst offender being Sun .RAS files which are also known as .RF, .RS, .IM1, .IM8 and .IM24 files, thus counting for six of the formats and variations.
The first column is the file extension or file type code. Extensions are used on PCs and other computers to identify the type of file and usually are several letters preceeded by a period placed at the end of a file name. For example, if the file’s name is “bigpict.bmp”, the “.bmp” part is the extension and indicates (if this is from an IBM PC or compatible) that the files is (or rather is likely) a Windows BMP file. I say “is likely” because with a limit of eight characters, the period and three characters for an extension, some of the more obvious extensions tend to get used by several different programs for completely different files. Worse, in many cases, there is no way to tell these variants apart.
On the Mac, each file is marked with a signature, a four letter code which identifies the program which created the file and a type, another four letter code which represents what’s in the file. Since both upper and lower characters are distinct, there are 2,820,802,151 file types (not every character is allowed). As well, Apple asks each developer to register their types and signatures to try and prevent collisions. While some have happened, in over ten years, very few have.
The second column identifies which system the file is most likely to be found on. The third identifies the type of file: bitmap, vector, sound, animation or mixed format file. The next column gives a status on the format to indicate if it’s been tested, is untested, buggy or is known to fail. “Untested” does not mean “Doesn’t work”. What has happened is that Imagery supports many formats which are so obscure that I could not find a sample file for that format. So, if my documentation is right (and I got the code right) they should work.
The final column simply gives a description of the file type.
Along the bottom you’ll see several buttons. The OK and Cancel buttons are obvious. OK continues into the program while Cancel quits the program immediately. Save will save a text file of the formats listed in the box above the buttons and More gives you more copyright information of interest mostly to publishers and people who want to include Imagery with their collections.
Selecting Output Format
Selecting "Ok" for either of the previous two dialogs will take to you the output file format selection dialog shown below.
If you’re familiar with earlier versions of Imagery, you’ll notice a lot of new options. First, since Imagery can handle sound and animation files, some way to handle selections of output formats appropriate for those kinds of files was necessary. Worse, since you can drag drop a collection of files with sounds, bitmaps and movies all mixed together, simultaneous selections were necessary.
Fortunately, it’s not that difficult. The panel at the top of the dialog will tell you how many files are left to process and the name of the next file to process. Bitmap Output allows the selection of output format for bitmap files. Mode/Resolution options modify the output format for bitmaps where appropriate by allowing you to select preferred file type (monochrome, greyscale, palette or full 32 bit RGB - Imagery does not support 16 bit output at this time), preferred resolution, whether or not to add a Macintosh preview to EPSF files and whether or not to add a preview icon to the file (System 7 only).
JPEG output requires Quicktime. If Quicktime is not detected, this option will be dimmed.
Display output brings up a window with the image displayed in it. You can continue from this window by clicking on the close box, or by hitting the space bar.
EPSF files are Adobe Photoshop 2.5.1 compliant and seems to work correctly with Freehand 4.0 and other programs which can handle an EPSF file. They are also Adobe EPSF 3.0 compliant and are generated in ASCII format as recommended by the Adobe Redbook on Postscript, version 2.
You’ll note I stated that these are ‘preferred’ formats and option because in some cases, Imagery will override your choice and select a more appropriate format. For example, Lotus PIC files are vector files and selecting a bitmap format will be overridden in favour of PICT files. A future version will simply convert the PIC to the selected bitmap format - probably v1.9.1.
Sound Output allows you to select the preferred output format for sound files that are detected.
Movie Output allows you to select the preferred output format for animation and movie files which are detected. At the moment, only Quicktime MOOV files can be generated and require Quicktime. If Quicktime is not detected, this option will be dimmed.
Unlike previous versions of Imagery, this version will allow you to convert files one at a time, changing the output options for each file, or all at once using the same set of options for all files.
The Do All button will use the current settings on all files either drag-dropped or selected one at a time. If this button is pressed, you will not see the output format selection dialog again during this session. The Do One button will apply the current settings to the next file and then ask for new settings. Skip simply skips the next file. Save saves the current settings into the Imagery program. These settings will be used as defaults for output format from the time you save them onwards. As well, if you drag and drop a set of files onto Imagery while holding the Command key, the currently saved settings will be applied to all files automatically. This prevents any dialogs from being shown. Quit exits Imagery immediately.
Selecting Input
The next dialog will be the Standard File Selector and you may repeated select image files until all conversions are complete. Selecting "Cancel" will end the program. As each file is processed a status window will inform you about the file being processed and of the current status.
Since the image files will all be coming from non-Macintosh systems which do not use the Mac's file signature system, there is a problem identifying a graphic file and its internal format. On other systems, a unique - well, mostly unique - extension, typically of three letters, is used to identify the file type. I say "mostly unique" because in fact, there are several major cases where wildly differing file formats have the same extension.
To make things simpler, Imagery looks at the file's extension just as a program on one of the other computer systems would and then presumes the image format. Many of the translators also do several checks on the file to confirm that the format matches the extension, but many either do not or cannot (Atari files are the worst for this). The previous file list will give you the required extensions for all formats currently supported.
Saving Output
The program will analyse each file in turn and then generate a new file by appending ".TIFF" to the end of the file and assigning it a "TIFF" signature. This will allow most program which can recognise the TIFF type to see these generated files. A standard output file selector will be displayed:
Animation files, or composite format files such as GRASP will generate multiple files. If there is a mechanism to identify the files within the source file, then the files will be given those names. Otherwise, they will take on the source file's name with a number appended to it.
With these files, you specify the destination for the first file and then that file and all other components will be saved into the same place.
Raw File Import
Imagery now includes a "raw" file import. This allows a knowledgable user to try and decypher and extract a usable image from an unknown or damaged file. Unfortunately, there are so many possible file formats and file compression methods that not all possible files can be imported using this module. Also, the number of parameters and variations makes using this more complex than would be desired.
